Is this taking ANY priority? Or is it that we'll get the OpenGL version after Firefox 6 gets released 3 years later...

Lots of Linux developers but much fewer Linux users. There are priorities here and plenty of betas left. Besides, this specific bug is bran new; give it at least a little time to have some activity. Please don't whine in tracking bugs. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I'm just worried about when it will be implemented. + I've heard that they will be using Xrender also which I've heard only works well for ATI's fglrx...

Should probably depend on bug 594308 and bug 580410, too?

(In reply to comment #4) Yeah, added. I think they just got lost here when OSX and Linux were split into two different OpenGL tracking bugs.

I have an ATI card with OSS driver. Please tell me which nightly build it is worth to start testing. I can't run any test suite but I can test normal browsing.

(In reply to comment #6) > I can't run any test suite Actually, yes you can, and easily using an extension: http://jagriffin.wordpress.com/2010/08/30/introducting-grafx-bot/ Do so and you can send your results to be aggregated and investigated for better hardware support for everyone. :)

Yes, I can do this, thank you for your hint.

Requesting blocking betaN+ or beta7+ if we want feature parity with Mac for OpenGL (bug 580405). Joe Drew?

I don't think we're going to be in a position to be able to turn OpenGL on by default. I will very happily take all the bugs that make it possible to do so, but I think we're going to end up needing to have an opt-in checkbox. (We might be able to whitelist certain drivers, like the NVIDIA proprietary driver and maybe the free ATI driver, but we've seen a lot of very bad bugs with the current driver situation on Linux, and I don't want to commit to turning OpenGL on by default for that reason.)

Thanks for the info Joe. That's pretty much what I expected, unfortunately.

(In reply to comment #10) > We might be able to whitelist certain drivers, like the NVIDIA > proprietary driver and maybe the free ATI driver Is there a separate bug for this, or do we need to file one? (or is that to be handled in this bug?) Nice to know that the free ATI driver, which I am currently using, is a possibility... ;)

(rearranging bug title wording so the Linux and Mac tracking bugs don't look exactly the same in bugmail when truncated; don't bury the lead)

I get this in my mail - What |Old Value |New Value ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE

We also need to make sure this gets disabled in the aurora branch next week, what do I need to do to track that?

I did enabled hardware acceleration, but I got half the FPS to that in chromium.

Comment on attachment 533146 [details] [diff] [review] Turn OpenGL on by default for linux When you land this, set tracking-firefox6 to ? so we're sure to back this out in Aurora for fx6.

Landed as http://hg.mozilla.org/mozilla-central/rev/f9a070327df8 and then backed out because of Mochitest failures http://hg.mozilla.org/mozilla-central/rev/5373d5d7e0f1

Matt, was this orange on try?

Not when I last tried it, but it may have been when texture_from_pixmap was broken.

Rebased and fixed the mochitest for this change. Carrying forward r=joe

Looking good on tryserver, trying this again! http://hg.mozilla.org/integration/mozilla-inbound/rev/0a920411e64c Fingers (and toes) crossed.

I believe one of the changesets in that push (bug 594876, bug 675474 or bug 675532) has caused an OSX 10.6 reftest perma-orange, so needs backing out: http://tbpl.allizom.org/?tree=Mozilla-Inbound&usebuildbot=1&rev=0a920411e64c

Backed out on inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/7797172fc164 http://hg.mozilla.org/integration/mozilla-inbound/rev/955f83dc4372

Note that Talos reported massive perf regressions on Linux for the push this was part.

... for the push this was part of. I see that Matt filed bug 680817 on this.

I just pushed to try with the pref layers.acceleration.force-enabled = true to get an idea of the current situation on Linux: https://tbpl.mozilla.org/?tree=Try&rev=673649ad7d36 I did not disable xrender. It may be worth trying also with gfx.xrender.enabled = false if this does not show good results.

(In reply to Nicolas Silva [:nical] from comment #27) > I just pushed to try with the pref layers.acceleration.force-enabled = true > to get an idea of the current situation on Linux: You can see a recent try build here: https://bugzilla.mozilla.org/show_bug.cgi?id=787853#c10

Adapter DescriptionATI Technologies Inc. -- AMD Radeon HD 6900 Series Vendor IDATI Technologies Inc. Device IDAMD Radeon HD 6900 Series Driver Version4.2.11762 Compatibility Profile ContextWebGL RendererATI Technologies Inc. -- AMD Radeon HD 6900 Series -- 4.2.11762 Compatibility Profile Context GPU Accelerated Windows1/1 OpenGL with xrender set to false even the current aurora seems to work. Not quite sure how i tell if its working though - about:support seems to indicate it is. performance isnt much different. there are a few transient image artifacts but otherwise it seems ok.

(In reply to paulf from comment #29) > with xrender set to false even the current aurora seems to work. And what with xrender enabled? > there are a few transient image artifacts but otherwise it seems ok. If you can reproduce these artifacts on a particular page, please file a new bug blocking this one.

(On my radeon OSS driver with forced layers acceleration the rendering is steadily improving with each Firefox nightly for the last year. Where there was flickering and rendering artifacts all over the page, I can see no problems today. I just don't see any perf advantage, but it works. Even WebGL works. Good work guys!)

With xrender enabled there are the usual ati fglrx bugs. i have one open for that. the artifacts are transient. 1 - sometimes the color scheme is messed up in gmail. currently its perfect. 2 - sometimes the background flickers moving images in blogger when composing a post. as im not actually sure if the opengl layers are working at all i didnt want to be raising bugs against it. i can do some retesting if need be - but i would like to know if layers are working as intended or at all or if there are still components missing from the gfx stack ?

(In reply to paulf from comment #29) > GPU Accelerated Windows1/1 OpenGL This means 1 out of 1 windows is using GL layers. i.e. OpenGL is used to composite the layers, as intended. Probably the most noticeable improvement in performance at this stage would be with high frame-rate WebGL such as https://developer.mozilla.org/en-US/demos/detail/bananabread Scaled webm/ogg video should also use less CPU. http://videos.mozilla.org/serv/marketing/sfx_edutoolkit/asa_historymozilla.ogv Also expect improvements scrolling LCD antialiased text over fixed backgrounds, but bug 777170 means that is not yet working as intended.

FYI, with Intel SandyBridge and quite recent kernels and X.org versions, GL layers have been working fine in Nightly for all cases I saw recently - I had the bounding boxes of doorhangers not being transparent for a while (with my custom theme, but without GL layers it was fine), but that has been fixed very recently as well. As this machine is really fast overall, I can't speak for performance. On hardware and systems like this, I'd feel good with having this turned on by default in Nightly in the near future to get more feedback. Good work, guys! :)

Very stable on Sandybridge now. The previously observed slowdowns or graphical anomalies are gone. Linux 3.6 Xorg 1.13.99 Mesa 9.1-devel Intel DDX git Nouveau DDX git

Seems to work pretty well on ivybridge too: ubuntu 12.10 kernel 3.5 mesa 9.0 intel 2.20.9 No more artifacts in the interface and scrolling like there used to be, seems to be quite usable. I'll have to give it more testing though.

ivy bridge has a small problem. In the google search suggestions, sometimes it's going to show a blank list (with the lists's black border but no entries in it). Also, what about benchmarking? It should be at par to other platforms.

I ran a few benchmarks on the ie10 testdrive site and some of them are still significantly slower than xrender. The most obvious example was psychedelic browsing. 7k+ with just xrender, and around 300 with layers enabled.

(In reply to Brandon Watkins from comment #39) > I ran a few benchmarks on the ie10 testdrive site and some of them are still > significantly slower than xrender. The most obvious example was psychedelic > browsing. 7k+ with just xrender, and around 300 with layers enabled. What hardware?

ivybridge i5-3210m 2.53ghz, 8gb ram on ubuntu 12.10

With xrender disabled, https://webglsamples.googlecode.com/hg/aquarium/aquarium.html is marginally faster; but it should be a lot faster.

Maybe that could be usefull in the future : GLX_MESA_query_renderer should soon be in Mesa thnaks to Ian Romanick [1] "The glXQueryRendererIntegerMESA and glXQueryRendererStringMESA functions allow applications query a bunch of aspects about the driver and hardware before creating a context: Driver version Driver vendor Hardware vendor (may be different from driver vendor!) Hardware chipset (PCI ID) Available memory UMA vs. non-UMA Supported and prefered (by the driver) GL profiles" [1] http://www.paranormal-entertainment.com/idr/blog/posts/2013-03-01T23:15:18Z-GLX_MESA_query_renderer_out_for_review/

I am having this problem too. My notebook is good, but the WebGL graphics is very slow. I am using Ubuntu 13.04, 64 bits, Firefox updated with last version.

Coming from bug 1060406, this issue causes a huge CPU consumption when playing some videos on my hardware (Intel graphics cards on Linux : one Ivy bridge and one Atom). Some VP8 or VP9 videos are playing fine on Totem but don't play at all on Firefox because of lack of CPU power. I read the workarounds above of setting layers.acceleration.force-enabled=true and/or gfx.xrender.enabled=false but they did not work for me : the about:support page always says 0 accelerated windows and the CPU consumption remains the same. Is there any way to manually enable accelerated windows on Intel graphics cards on Linux? NB : using Firefox 33 (64 bits) from Ubuntu 14.04 standard repos. Same behavior with Firefox 31 downloaded from Mozilla

(In reply to Mossroy from comment #47) > Coming from bug 1060406, this issue causes a huge CPU consumption when > playing some videos on my hardware (Intel graphics cards on Linux : one Ivy > bridge and one Atom). > Some VP8 or VP9 videos are playing fine on Totem but don't play at all on > Firefox because of lack of CPU power. > > I read the workarounds above of setting > layers.acceleration.force-enabled=true and/or gfx.xrender.enabled=false but > they did not work for me : the about:support page always says 0 accelerated > windows and the CPU consumption remains the same. > > Is there any way to manually enable accelerated windows on Intel graphics > cards on Linux? > NB : using Firefox 33 (64 bits) from Ubuntu 14.04 standard repos. Same > behavior with Firefox 31 downloaded from Mozilla Video acceleration using GStreamer would be bug 894372.

Thanks Marco, but I don't think we're talking about the same thing. If I understood correctly, the bug 894372 you mention is about activating hardware decoding through GStreamer+VAAPI. The tests I made were with VP8 and VP9 video codecs, which are not decoded by Gstreamer as far as I know. And, in any case, my hardware does not support hardware VP8/VP9 decoding. Based on the comments in bug 1060406, it seems that the CPU overhead I face would be due to Firefox window composition. It seems to depend on the hardware : some people with OpenGL accelerated windows do not have this overhead. I believe this is why it has been marked as duplicate of this issue. I'd like to check these assumptions by manually enabling accelerated windows in Firefox (if it's possible)

(In reply to Mossroy from comment #49) > Thanks Marco, but I don't think we're talking about the same thing. > If I understood correctly, the bug 894372 you mention is about activating > hardware decoding through GStreamer+VAAPI. > The tests I made were with VP8 and VP9 video codecs, which are not decoded > by Gstreamer as far as I know. And, in any case, my hardware does not > support hardware VP8/VP9 decoding. > > Based on the comments in bug 1060406, it seems that the CPU overhead I face > would be due to Firefox window composition. It seems to depend on the > hardware : some people with OpenGL accelerated windows do not have this > overhead. I believe this is why it has been marked as duplicate of this > issue. > > I'd like to check these assumptions by manually enabling accelerated windows > in Firefox (if it's possible) layers.acceleration.force-enabled and a restart of the browser should be all that's required to trigger OpenGL+OMTC, though there may be blacklisted drivers now. For basic (non-opengl) OMTC you can enable layers.offmainthreadcomposition.enabled with acceleration disabled

Thanks John. I tested layers.offmainthreadcomposition.enabled (with acceleration disabled). It had no significant effect on my computers. So I suppose the Intel open-source drivers I use on these computers are blacklisted? How could I check that? If someone could point me to where this blacklist is (in the source code, I suppose), I might try to remove it and recompile?

On linux, unless you are using firefox nightly, you also need to set either of these two environment variables: export MOZ_USE_OMTC=1 export MOZ_OMTC_ENABLED=1 in addition to the prefs. There are historical reasons to that but in short, need to initialize X in thread-safe mode before the service that can read prefs is created (so at a point where we can only use environment variables). We didn't want to initialize X in thread-safe mode unless OMTC is activated because it adds a bit of overhead. The plan is to enable OMTC on linux for everyone asap, but we are getting delayed by some fire fighting on windows at the moment, but soon-ish this should become easier.

Thanks Nicolas. With these environment variables set and layers.acceleration.force-enabled=true, I manage to have an accelerated window in about:support : "1/1 OpenGL (OMTC)" Unfortunately, it does not seem to make a visible difference when playing my test WebM videos : the CPU consumption is still ~ twice more than with Totem, and the video is still choppy on the netbook (while smooth in Totem) Can I test anything else?

(In reply to Mossroy from comment #53) > Thanks Nicolas. > With these environment variables set and > layers.acceleration.force-enabled=true, I manage to have an accelerated > window in about:support : "1/1 OpenGL (OMTC)" > > Unfortunately, it does not seem to make a visible difference when playing my > test WebM videos : the CPU consumption is still ~ twice more than with > Totem, and the video is still choppy on the netbook (while smooth in Totem) > > Can I test anything else? Maybe your local installation or the recent entanglement of layers.acceleration.force-enabled and OMTC is the problem. You could try an older live system like Ubuntu 13.10 64-bit (including Firefox 24 without OMTC): Download Ubuntu 13.10 64-bit from http://releases.ubuntu.com/13.10/ burn it, boot it, select "Try Ubuntu" (not install), set layers.acceleration.force-enabled to true, restart Firefox and see if the CPU usage of your WebM video gets reduced.

Thanks a lot Cresto, you were right! With Firefox 24 (from Ubuntu 13.10), setting layers.acceleration.force-enabled to true is enough to get hardware accelerated window in about:support : "1/1 OpenGL" It's still OK with Firefox 26 (from Mozilla), but fails since Firefox 27 (from Mozilla : "0/1 Basic") SO I suppose the regression has been introduced in Firefox 27. The CPU usage is indeed reduced with OpenGL acceleration. Here are the approximate CPU consumptions I have with a WebM video (VP8+Vorbis) played on an old netbook (Atom dual core N570 @1.66GHz with HT) Firefox 26 : 90% + 16% compiz + 16% xorg + 8% pulseaudio (total = 130%) Firefox 27 (or Firefox 26 without layers.acceleration.force-enabled to true) : 110% + 30% compiz + 13% xorg + 8% pulseaudio (total = 161%) By comparison : Totem : 65% + 13% compiz + 13% xorg + 5% pulseaudio (total = 96%) Chromium 34 : 135% (3 processes : 90+25+20) + 18% compiz + 13% xorg + 18% pulseaudio (total = 184%) To sum up, there is still an overhead when compared with Totem, but having OpenGL accelerated windows is really worth it, as it reduces this overhead in a noticeable way. I hope the following versions of Firefox will fix these issues : at least allow to force-enable OpenGL, and at best enable it by default NB : I tested with Firefox nightly (36.0a1) in the same conditions. The about:support says "1/1 OpenGL (OMTC)", and the CPU consumption is : 135% + 20% compiz + 20% xorg + 5% pulseaudio (total = 180%. Not sure this test is relevant because it seems that Firefox nightly eats ~35% CPU, even when idle)

Is there any progress on this one? At leats with the open-source drivers (radeon, intel), Firefox works well with opengl acceleration turned on.

(In reply to Clemens Eisserer from comment #56) > Is there any progress on this one? > At leats with the open-source drivers (radeon, intel), Firefox works well > with opengl acceleration turned on. At the moment it's best to wait for the transition gtk2->gtk3 to be done and stable before we ship another change that greatly impact the graphics pipeline on linux. We also need to figure out whether the servers we run tests on have have a reliable graphics stack and have them run tests with opengl compositing in addition to the software compositing configuration, and figure out the remaining issues (there are open bugs about gl compositing on linux, I don't think that it is free of regressions at the moments, even if it mostly works well). There are also other things to do on linux like moving away from cairo's xrender backend, that have an impact on the compositing backend so we have to figure out what the dependencies are there.

(In reply to Clemens Eisserer from comment #56) > Is there any progress on this one? My last post sounded perhaps a bit pessimistic, but to answer your question more directly, :acomminos has made some progress on this front, lately.

(In reply to Nicolas Silva [:nical] from comment #57) > At the moment it's best to wait for the transition gtk2->gtk3 to be done and > stable before we ship another change that greatly impact the graphics > pipeline on linux. But GTK+ 3 already is enabled by default now: https://bugzilla.mozilla.org/show_bug.cgi?id=1186003 ? (In reply to Nicolas Silva [:nical] from comment #57) > There are also other things to do on > linux like moving away from cairo's xrender backend, that have an impact on > the compositing backend so we have to figure out what the dependencies are > there. Do you have a link? Regards

(In reply to nw9165-3201 from comment #59) > But GTK+ 3 already is enabled by default now: It hasn't made it to the release channel yet. Regressions from these kind of changes usually show up only when the new feature hits a large population of users, so waiting a bit between risky changes helps with being able to react quickly when bugs show up in the beta or release channels (and more importantly not having too many of these late bugs at the same time to deal with). Gtk3 isn't in a worrying state as far as I know so we should be good soon. > (In reply to Nicolas Silva [:nical] from comment #57) > Do you have a link? Bug 1180942

Review commit: https://reviewboard.mozilla.org/r/59522/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59522/

Review commit: https://reviewboard.mozilla.org/r/59524/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59524/

Review commit: https://reviewboard.mozilla.org/r/59526/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59526/

It seems like a good time now to enable this on Nightly; these patches enable layers acceleration by default on GTK. Let's triage, start making use of the downloadable blocklist, and improve glxtest as we start getting data in from nightly users.

Comment on attachment 8763264 [details] Bug 594876 - Accelerate layers by default for nightlies on Linux. https://reviewboard.mozilla.org/r/59526/#review56620

Comment on attachment 8763263 [details] Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. https://reviewboard.mozilla.org/r/59524/#review56622

Comment on attachment 8763262 [details] Bug 594876 - Fuzz reftests with noise from enabling layers acceleration on Linux. https://reviewboard.mozilla.org/r/59522/#review56624 \o/

Pushed by acomminos@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/5bde2c12831c Enable layers acceleration by default on Linux. r=nical https://hg.mozilla.org/integration/mozilla-inbound/rev/d8b83ff870a3 Test that acceleration is used on Linux. r=nical https://hg.mozilla.org/integration/mozilla-inbound/rev/cafa7213ef23 Fuzz reftests with noise from enabling layers acceleration on Linux. r=nical

Backed out for failing reftest preserves3d-nested.html at least on Linux: https://hg.mozilla.org/integration/mozilla-inbound/rev/c583dc0f3f4a2fd3e0d4b478a599c1f613085d52 https://hg.mozilla.org/integration/mozilla-inbound/rev/a79452abaf55f1cfb37f943924e02e54e1d23c4a https://hg.mozilla.org/integration/mozilla-inbound/rev/3ce999f6a0ef50904d7d7ebf8463ba2c70ef8028 Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=cafa7213ef23c20fd5774db249db63b07314dcd9 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=30271778&repo=mozilla-inbound

Sorry, reftest fuzz order was incorrect for that test. Will fix and reland when I get back.

Be aware that the push had many timeouts in various mochitests. Please push to Try if it isn't obvious that the changes fill fix these.

With larger AWS instances, the software GL infrastructure in bug 1296086 landing, and better Linux blocklisting, we have a better chance at making this stick. Let's make it exclusive to nightly builds for now, and see how things go.

Due to bug 1296086, test_acceleration.html has been flagged TODO (as we only accelerate on TaskCluster tests). Thanks!

Comment on attachment 8763263 [details] Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. https://reviewboard.mozilla.org/r/59524/#review70500

Comment on attachment 8763263 [details] Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. https://reviewboard.mozilla.org/r/59524/#review70502

Comment on attachment 8763263 [details] Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. https://reviewboard.mozilla.org/r/59524/#review70618

Pushed by acomminos@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/314eb9761599 Fuzz reftests with noise from enabling layers acceleration on Linux. r=nical https://hg.mozilla.org/integration/autoland/rev/f35636ae9fdb Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. r=nical https://hg.mozilla.org/integration/autoland/rev/32fd2e8a3be8 Accelerate layers by default for nightlies on Linux. r=nical

https://hg.mozilla.org/mozilla-central/rev/314eb9761599 https://hg.mozilla.org/mozilla-central/rev/f35636ae9fdb https://hg.mozilla.org/mozilla-central/rev/32fd2e8a3be8

Thank you!

I have before the layers accelerated, the only thing I have noticed is the noise on the browser, apart with my hd 4600 intel hd and arch linux all is going well

I think I was bitten by the fix for this ticket. Details here: https://bugzilla.mozilla.org/show_bug.cgi?id=1299588

Just found a side effect of this fix on Ubuntu 12.04 x32 where the latest Nightlies (since the fix) fail to start on the machine. Using the following 2 prefs "layers.acceleration.force-enabled:false" and "layers.acceleration.disabled:true" makes the issue go away. Ubuntu 14.04 x64 works as expected.

(In reply to Ciprian Muresan [:cmuresan] from comment #87) > Just found a side effect of this fix on Ubuntu 12.04 x32 where the latest > Nightlies (since the fix) fail to start on the machine. > Using the following 2 prefs "layers.acceleration.force-enabled:false" and > "layers.acceleration.disabled:true" makes the issue go away. > > Ubuntu 14.04 x64 works as expected. This is probably the same issue that mirh pointed out in bug 1298333 comment 6.

(In reply to Marco Castelluccio [:marco] from comment #88) > This is probably the same issue that mirh pointed out in bug 1298333 comment > 6. It seems so, thanks for pointing that out.

(In reply to Ciprian Muresan [:cmuresan] from comment #89) > (In reply to Marco Castelluccio [:marco] from comment #88) > > This is probably the same issue that mirh pointed out in bug 1298333 comment > > 6. > > It seems so, thanks for pointing that out. Do you have the same gfx card and same driver version? If you don't, perhaps you can add a comment in that bug saying what yours are.

Would it make sense to add bug 1306912 to the "depends on" list?

(In reply to Clemens Eisserer from comment #91) > Would it make sense to add bug 1306912 to the "depends on" list? Yes, done.

and another one please: 1306974 I only see this issue when OpenGL is enabled, and haven't experienced it with earlier versions (48/49(?)) - so either a firefox or mesa regression.

Lee, please reopen this once you fix bug 1323284, turning acceleration off by default.

As part of bug 1323284, we disabled acceleration again until we have time/resources to better investigate this. Reopening...

I'm experiencing heavy scrolling lag and jerky controls with FF 45.8 ESR on Linux Debian (i686/32bits). Disabling hardware acceleration had no effect.

(In reply to Etienne Robillard from comment #96) > I'm experiencing heavy scrolling lag and jerky controls with FF 45.8 ESR on > Linux Debian (i686/32bits). Disabling hardware acceleration had no effect. You can try toggling the gfx.xrender.enabled pref and see if it helps either way.

(In reply to Lee Salzman [:lsalzman] from comment #97) > You can try toggling the gfx.xrender.enabled pref and see if it helps either > way. I tried disabling gfx.xrender.enabled without any effects. Furthermore, I don't understand the logic of disabling XRender for local X11 connections.

Not sure the meta bug is the right one to discuss that... Also not sure why (in such a.. _complex and longstanding_ issue) reporting issues with a 1 year and half old codebase would really help anything when all the developments happens on builds with a 10 higher number.

What's the status/forward plan here? I see quite a few dependencies however it's a bit unclear how many of them are blocking enabling by default and which could be dealt with afterwards (or while riding the trains). Do you have a rough time estimate (in terms of trains) when you think this is worthwhile to pick up (i.e. enable by default)?

No current timeline or solid plans.

Is this meaning linux version won't get webrender? (as it need HW_COMPOSITING to work)

I think the importance of this issue should not be underestimated. It has a direct impact on "user-experience", and "user-experience" has a direct impact on market share. I know, because I was even considering switching over to Windows just so I could use the Microsoft Edge browser. Why? Because for years I've watched on in envy as my work colleagues smoothly scrolled around the heaviest of web pages on the Interwebs. It's like they were gliding on ice, while my scrolling made it look like skating on cobble stones. On Kubuntu 18.04 (on 3 computers), I went in to about:config and set layers.acceleration.force-enabled to true. The difference is like night and day. Moving back to Windows is something I really didn't want to do, and thankfully, I don't have to now because I too am skating on ice. I still get the odd "jank" ("micro-stutter" - whatever it's called), but it has become the exception rather than the rule. I know that "smoothness" can be very subjective, but here's the test I use: 1. Open Google's homepage. 2. Click on the "Images" link. 3. Do an image search for something (e.g. "cars"). 4. Click on the middle-button to activate auto-scroll. 5. Move the mouse cursor about 1cm below the "auto-scroll circle. 6. Just observe the page as it scrolls downwards. On a default installation of Kubuntu 18.04 on: * My desktop (with an Nvidia 1070 with 6GB of RAM) * My T470 laptop (with an Intel 520 iGPU) * My T470p laptop (with an Nvidia 940mx with 2GB of RAM) performing the above steps results in jittery and jerky scrolling - in other words, a terrible user-experience. Such an issue (and I do believe it's an important issue) is not easy for the average user to articulate. Their brains perceive something is wrong and not working "quite right", but they don't know how to explain it and they simply form a negative opinion. Many years ago Intel commissioned a project whereby they reverse engineered the iOS user-experience (they wanted to find out why Apple was so successful, despite running on lower-end hardware and slower CPUs with less cores). The conclusion was definitive: * The operating system managed to consistently maintain 60 frames per second. * There was only 6 (or so) milliseconds of touch input lag (compared to Androids whopping 200ms in some cases). That is the secret sauce - a successful implementation of the whole "touch paradigm". The same can be applied to the desktop experience, although with the desktop experience input lag isn't as important (most of the time). Make the experience "smooth", and users "feel" good. Hardware acceleration is imperative to achieve this!!

(Just a community member) (In reply to Scott Deagan from comment #104) Hi, I think nobody will touch this old feature. I share your position and there's light at the end of the tunnel! > managed to consistently maintain 60 frames per second. That's exactly why you want to try out WebRender: https://nightly.mozilla.org (Windows, Linux, Mac), gfx.webrender.all;true, restart. It's developed in Rust (https://www.rust-lang.org), so it's more secure, it's also using OpenGL and there is a project porting it to Vulkan, DX12 and Metal based on an abstraction layer. Presumably, it will be enabled by default in Fx 64 for Nvidia on Win10. Other graphics cards, Linux, Mac and Android will follow afterwards. You might want to follow: * https://mozillagfx.wordpress.com/ * https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx * https://github.com/servo/webrender/

Yeah, exotic, old and mobile configurations can't expect too much at the moment.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #105) Thanks! Good to know what's in the pipeline, but at the moment I have found a "solution" (?) that works for me right now. In the 10 years or so that I've been using Linux, this is the first time I have experienced "buttery smooth scrolling" - and while some may dismiss this as being "just scrolling", to me it makes all the difference. Again, it's subjective because it's "user-experience", but I'm sure others will be negatively impacted the same way I was. Anyway, my point is I consider myself a fairly advanced user, and it took me 10 years to finally achieve something I've been wishing for since I started using Linux. It would be nice if "smooth" was the default, and not something users have to find very technical configuration tweaks to achieve (because most users won't). I'll have a read about WebRender and will try it out. Again, thanks for pointing this out.

"Other graphics cards, Linux, Mac and Android will follow afterwards" I sure hope so, but we've been told this before. The old opengl layers were supposed to be enabled on linux 'eventually' too, but it never happened, and in 2018 linux users are stuck without any hardware acceleration by default.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #105) > Hi, I think nobody will touch this old feature. I share your position and > there's light at the end of the tunnel! > > > managed to consistently maintain 60 frames per second. > > That's exactly why you want to try out WebRender: > https://nightly.mozilla.org (Windows, Linux, Mac), gfx.webrender.all;true, > restart. > > It's developed in Rust (https://www.rust-lang.org), so it's more secure, > it's also using OpenGL and there is a project porting it to Vulkan, DX12 and > Metal based on an abstraction layer. Presumably, it will be enabled by > default in Fx 64 for Nvidia on Win10. Other graphics cards, Linux, Mac and > Android will follow afterwards. Since WebRender deepends on hardware compositing, isn't enabling WebRender by default on Linux blocked on this bug?